Inhalt: Details ber die Untersttzung einer FPU in einigen Modulen.

Hnisch, TDI, LPR und SPC verwenden grundstzlich das IEEE-Format fr
reelle Zahlen, so da es mglich ist, eine FPU vom Typ 68881/2 zu
benutzen, ohne da dafr an anderer Stelle etwas gendert werden mte.
Es ist damit auch mglich, Routinen zu verwenden, die zur Laufzeit testen,
ob eine solche FPU vorhanden ist; so knnen die Bibliotheksroutinen
automatisch die fr den gegebenen Rechner optimalen Routinen verwenden.
Megamax dagegen hat fr die per Software ausgefhrten Berechnungen mit
reellen Zahlen ein eigenes Format, das nicht mit dem IEEE-Format kompatibel
ist. Je nach verwendetem Format ist u.a. auch ein unterschiedliches
Laufzeitsystem zu linken. Deshalb ist es nicht mglich, zur Laufzeit
zwischen den Formaten zu wechseln und so automatisch eine FPU zu verwenden.
Zudem scheint es erforderlich zu sein, eine FPU im Rechner zu haben, um
berhaupt entsprechenden Code bersetzen zu knnen.
Aus diesem Grund wurde keine FPU-Untersttzung fr Megamax implementiert.

Folgende Module benutzen die FPU, falls vorhanden:
'LowReal', 'LowLong', 'RealSupport', 'LongSupport', 'RealMath', 'LongMath',
'RealXMath', 'LongXMath'. Dazu kommt dann noch das Modul 'jump', das
gegebenenfalls auch die FPU-Register rettet, und das Modul 'DosSystem',
das eine Hilfsfunktion enthlt.
In diesen Modulen wird zu Programmbeginn ber den Cookie '_FPU' festgestellt,
ob eine 68881, 68882 oder eine F-Line-Emulation vorhanden ist, und dieses
dann in der bool'schen Variable 'hasFpu' vermerkt. Ein 68040-Prozessor gilt
dabei ebensowenig als FPU, wie eine als Peripheriekarte (SFP004) ansprechbare
FPU. Bei Aufruf einer der entsprechenden Prozeduren wird dann anhand des
Flags 'hasFpu' die passende Berechnung gewhlt.

Bei den per Software ausgefhrten Berechnungen lt sich beim Prprozessieren
whlen, ob Ausnahmen ausgelst werden sollen, wenn die Argumente der
Funktionen nicht im Definitionsbereich liegen oder sonst irgendetwas nicht
stimmt. Bei den durch die FPU ausgefhrten Berechnungen ist dies nicht der
Fall, da die FPU selbst auf gltige Werte prft. Wenn die FPU einen Fehler
feststellt, wird eine FPU-interne Ausnahme ausgelst, wobei es nun zwei
Mglichkeiten gibt: Wenn die Ausnahmen im Kontrollregister FPCR aktiviert
wurden, wird ein Softwareinterrupt (Trap) ausgelst; dafr mu dann natrlich
ein entsprechender Trap-Handler vorhanden sein, der je nach Art des Fehlers
reagiert. Ist die jeweilige Ausnahme deaktiviert, wird nur ein entsprechendes
Flag im Statusregister FPSR gesetzt und ein Wert als Funktionsergebnis
zurckgeliefert, der ein Problem signalisiert. Dies kann je nach
Rundungsmodus, Fehler und Funktion +/-Unendlich, NaN oder die grte
darstellbare Zahl sein. Normalerweise werden die Flags im Statusregister
vor jeder Funktion zurckgesetzt, so da eine berprfung nach jeder
FPU-Instruktion erfolgen mte; es gibt allerdings auch das
"Accrued Exception Byte", in dem die Fehler aller bisheriger ausgefhrter
FPU-Instruktionen gesammelt werden. Auf diese Weise ist es mglich, eine
komplette Berechnung (z.B. eine der Funktionen aus den oben genannten
Modulen, die zumeist aus mehreren FPU-Instruktionen bestehen) durchzufhren
und erst zum Schlu zu testen, ob etwas schief gegangen ist.

Mit den Funktionen "currentMode()" und "setMode()" aus den Modulen
'LowReal' bzw. 'LowLong' lassen sich die wichtigsten Dinge im FPU-Register
FPCR abfragen bzw. setzen. Dazu gehrt, neben der Einstellung des
Rundungsmodus' und der Rundungsgenauigkeit, auch die Aktivierung bzw.
Deaktivierung der FPU-Traps. Defaultmig sind die Traps abgeschaltet,
d.h. Fehler werden ber den Funktionswert bzw. das Statusregister
mitgeteilt. Wenn die Traps aktiviert werden (es gibt mehrere fr verschiedene
Fehlerklassen) mssen allerdings auch entsprechende Traphandler
bereitgestellt werden, die nicht in M2LIB enthalten sind.

Mit den Funktionen "GetIEEEfpState()" und "ResetIEEEfpState()" aus dem
Modul 'DosSystem' lt sich das "Accrued Exception Byte" des FPU-Registers
FPSR abfragen bzw. zurcksetzen, d.h. mit diesen beiden Funktionen kann bei
deaktivierten FPU-Traps eine Fehlerbehandlung durchgefhrt werden.

Da das Verhalten von Software- und FPU-Berechnungen nicht 100%-ig identisch
ist, vor allem was die Ausnahmen bei Fehlern betrifft, kann es mglicherweise
sinnvoll sein, die automatische Erkennung der FPU abzuschalten, so da
immer die Softwareversionen ausgefhrt werden. Hierzu mu nur im Rumpf
des entsprechenden Implementationsmoduls die Variable 'hasFpu' konstant
auf FALSE gesetzt werden. Ebenso kann es sinnvoll sein, einen 68040
als FPU zu akzeptieren, wenn dieser eine vollstndige FPU enthlt (ich
wei nicht, ob es das gibt). In diesem Fall wird eben die entsprechende
Abfrage durch Hinzunahme des Flags 'm68040' erweitert.


Grundstzlich ist Vorsicht geboten, wenn die FPU sowohl in einem ACC
als auch einer Applikation genutzt wird: ltere AES-Versionen sichern
beim Wechsel zwischen beiden nicht den FPU-Zustand. Das gleiche gilt auch
fr die parallele Benutzung in Applikationen unter lteren MiNT-Versionen.
Diese Probleme sind erst mit AES-Versionen 4.x und neueren MiNT-Versionen
(Version?) beseitigt.
Ausgerechnet bei Megamax, wo sie im Zusammenhang mit M2LIB nicht benutzbar
sind, gibt es allerdings genau solche Prozeduren (Modul 'FPUSupport'),
um den FPU-Zustand zu sichern und wiederherzustellen...
Im passenden Laufzeitsystem werden auch FPU-Interrupts eingeschaltet
und durch entsprechende Traphandler abgefangen, nur kann man eben nicht
zur Laufzeit die Benutzung der FPU ein- oder ausschalten.

Wer sich entsprechende Prozeduren selber basteln will, mu im
Supervisormodus sowohl den internen Zustand der FPU mit FSAVE/FRESTORE als
auch den nach auen sichtbaren Zustand mit FMOVEM sichern.

Literatur:
==========

o MC68881/MC68882 Floating-Point Coprocessor User's Manual. Motorola/
  Prentice Hall, Englewood Cliffs, N.J., First Edition, 1987
